C++: Map more expressions to OperandNodes#11781
C++: Map more expressions to OperandNodes#11781MathiasVP merged 2 commits intogithub:mathiasvp/replace-ast-with-ir-use-usedataflowfrom
OperandNodes#11781Conversation
|
I see result changes on DCA, is that expected? |
It's not. I would guess that these are due to changes to locations (or duplicated paths), but I haven't verified this yet. |
| or | ||
| node.(IndirectOperand).isIRRepresentationOf(_, _) | ||
| exists(Instruction def | | ||
| unique( | | getAUse(def)) = node.getOperand() and |
There was a problem hiding this comment.
What's the reason for the unique?
There was a problem hiding this comment.
We don't want the Expr -> Node direction to be a one-to-many relation. If there happens to be more than one use of the operand, then we'll fall back to picking the InstructionNode with the defining Instruction as the node for the expression.
There was a problem hiding this comment.
I guess this was implicitly achieved before by the much more restrictive definition of this predicate?
There was a problem hiding this comment.
Yeah, exactly. Previously we'd only map an expression to an operand when it was an argument of (or a result of) a function call. And in both cases (at least the argument case) there should always be a unique use.
There was a problem hiding this comment.
Yeah, I think so. When there's a unique use this predicate kicks in and ensures that that the Call expression is mapped to the dataflow node (and the Call expression has a pretty toString like call to getenv). And when there isn't a unique use we get the Instruction's Opcode's toString which is a lot less user-friendly.
There was a problem hiding this comment.
Yeah, that was on my list to fix anyway, so no need to solve it here.
There was a problem hiding this comment.
^ I think this is one of the issues we should tackle as part of the "prettify dataflow paths" issue 😄.
There was a problem hiding this comment.
Yeah, that was on my list to fix anyway, so no need to solve it here.
Ah, perfect!
There was a problem hiding this comment.
Yup, the prettifying issue that was what I was referring to 😄
jketema
left a comment
There was a problem hiding this comment.
This looks good to me in principle, but we need to have a closer look at the DCA alert changes.
Hmm... I looked at most of the new SAMATE results, and they are all duplicated paths. I still need to look at the real world results, though. |
|
Here's a rundown of the result changes: cpp/potential-system-data-exposure and cpp/cleartext-storage-file
cpp/uncontrolled-allocation-size
cpp/unbounded-write
|
0f93e5c
into
github:mathiasvp/replace-ast-with-ir-use-usedataflow
This fixes a performance problem I observed on
cmake. The problem happened in thegetBufferSize's predicate, where we have a case that searches backwards through expressions usingDataFlow::localExprFlowStep. The code that exhibited the performance problem looked something like:and, while
DataFlow::localFlowStepwould handle this code perfectly well, theDataFlow::localExprFlowSteppredicate (which has an additional transitive closure internally to step to the nearestDataFlow::Nodethat has anasExpr()result) would explode because the node that received flow from one assignment (i.e.,a[k] = ...;) to the next (i.e.,a[k+1] = ...;) wouldn't be the node that had a result forasExpr().This PR changes
asExprso thatExprflow will proceed asa[0] = ...;->a[1] = ...;->...->a[65536] = ...;->use(a[i]).